home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 737 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.1 KB
  1. From: Russell Gold <goldr@inet.bis.adp.com>
  2. Message-ID: <3149AC2A.42D2@bis.adp.com>
  3. X-Original-Date: Fri, 15 Mar 1996 12:43:06 -0500
  4. Path: in1.uu.net!bounce-back
  5. Date: 16 Mar 96 07:44:23 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Return-Path: <daemon@migs.UCAR.EDU>
  8. Newsgroups: comp.std.c++
  9. Subject: Re: Anyone considered inheritable friendship?
  10. Organization: Strategic Architecture
  11. References: <4fnrfr$7b1@engnews1.Eng.Sun.COM> <AFwV3Hn027@qsar.chem.msu.su>
  12. X-Mailer: Mozilla 2.0 (WinNT; I)
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBFAgUBMUpxYeEDnX0m9pzZAQH2CgF+ISS/R4gAfc74Pxr9r/3703GSEnlvkYcM
  15.     MnNOiYBpbY29uLXaA3czBEW+5jtqNel2
  16.     =eE4W
  17.  
  18. Eugene Radchenko wrote:
  19.  
  20. [ Steve Clamage comments that making inheritance inheritable is
  21.   roughly equivalent to making all members public, in terms of
  22.   its effects on maintenance ]
  23.  
  24. > But it is not. Inheritable friendship is a natural extension of
  25. > normal friendship (for tightly coupled classes) to tightly
  26. > coupled hierarchies.
  27.  
  28. Except that hierarchies are necessarily open, so making a 
  29. hierarchy a friend means that the original class becomes open to 
  30. classes which were never imagined by its author.  You can never 
  31. guarantee that a "tightly coupled hierarchy" will remain tightly 
  32. coupled.  AFAIK there is no prohibition on making multiple members 
  33. of the same hierarchy friends to the same class.  Doing this allows 
  34. the original author to restrict access to only those members of the 
  35. hierarchy which should have that access.
  36.  
  37. > In my project (that spawned the question) base class builds a
  38. > certain graph and derived classes decompose it in different ways 
  39. > using helper objects
  40. > from other hierarchies. Nobody except those objects (and original
  41. > object tree, of course) has any business to that graph.
  42.  
  43. So make each of those classes friends of the graph.
  44.  
  45. OR, you can use a little trick within the confines of the language.
  46.  
  47. class ThatGivesFriendship
  48.     :
  49.     
  50.   friend HierarchyBaseClass;
  51.   private:    // operations used by the hierarchy
  52.     short accessedInfo() const;
  53.     :    
  54.  
  55.   private:    // members only used by the class itself
  56.     :
  57.  
  58.   };
  59.  
  60.  
  61. class HierarchyBaseClass
  62.    :
  63.    :
  64.  
  65.   protected:
  66.     short tgfAccessedInfo( const ThatGivesFriendship *tgf ) const {
  67.           return tgf-> accessedInfo();
  68.           }
  69.  
  70.    :
  71.  
  72. In this scheme, every subclass in the hierarchy *does* have access 
  73. to those members of the relevant class without making friendship 
  74. inheritable.  Of course, here, you are specifically identifying the 
  75. interface between the classes, and stating that only members of the 
  76. hierarchy can use it.
  77.  
  78. And you can do all of this without modifying the language.
  79.  
  80. -- 
  81. Russell Gold         | (609) 727-2219    
  82. ADP, Inc.            | goldr@bis.adp.com
  83. 201 E. Park Dr.      | russgold@ACM.org                  
  84. Mt. Laurel, NJ 08054 | russgold@aol.com
  85. ---
  86. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  87. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  88. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  89. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  90. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  91.